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Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 
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GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 3 of the Evolved Packet System SlOl interface between the MME and the 
HRPD Access Network. The SlOl interface supports procedures for Pre-Registration, Session Maintenance and Active 
handoffs between E-UTRAN and HRPD networks. 

It also specifies the S103 interface between the Serving GW and HRPD PDSN. This User Plane interface is used to 
forward DL data to minimize packet losses in mobility from E-UTRAN to HRPD. Signalling procedures on the SlOl 
interface are used to set up tunnels on the S103 interface. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses". 

[3] IETF RFC 3232: "Assigned Numbers". 

[4] IETF RFC 2784: "Generic Routing Encapsulation (GRE)". 

[5] IETF RFC 2890: "Key and Sequence Number Extensions to GRE". 

[6] 3GPP TS 29.274: "Evolved GPRS Tunnelling Protocol for Conti'ol Plane (GTPv2-C); Stage 3". 

[7] 3GPP2 C.S0024- A v3.0: " cdma2000 High Rate Packet Data Air Interface Specification ". 

[8] 3GPP TS 23.007: "Restoration procedures". 

[9] 3GPP2 C.S0087-0: "E-UTRAN - HRPD and CDMA2000 Ix Connectivity and Interworking: Air 

Interface Aspects". 

[10] 3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 

3". 

[II] 3GPP TS 33.402: "3GPP System Architecture Evolution: Security Architecture". 

[12] 3GPP TS 36.413: "Evolved Universal Terrestrial Radio Access (E-UTRA) ; SI Application 

Protocol (SI AP)". 

[13] 3GPP TS 24.008: " Mobile radio interface Layer 3 specification; Core network protocols; Stage 

3". 

[14] 3GPP TS 29.280: "3GPP EPS Sv interface (MME to MSC) for SRVCC" . 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

HRPD Access: Combination of the eAN - PCF of the cdma2000 access 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

AN Access Network 

eAN enhanced AN 

eGTP enhanced Gateway Tunnelling Protocol 

eNodeB enhanced Node B 

E-UTRAN Enhanced UMTS Terrestial Radio Access Network 

ORE Generic Routing Encapsulation 

GW Gateway 

HO Handover 

HRPD High Rate Packet Data 

HSGW HRPD Serving GateWay 

IMSl International Mobile Station Identity 

IP Internet Protocol 

MME Mobility Management Entity 

PCF Packet Control Function 

PDN Packet data Network 

PDSN Packet Data Serving Node 

PMIP Proxy Mobile IP 

TEID Tunnel End Point Identifier 

UDP User Datagram Protocol 

VS Vendor Specific 

4 General 

The SlOl reference point is defined between the MME and the HRPD access, enabling interactions between E-UTRAN 
Access and cdma2000 HRPD Access. The SlOl interface is required to perform procedures related to optimise HO 
between the E-UTRAN Access and cdma2000 HRPD Access to allow for pre-registration and handover signalling with 
the target system. 

The SI 03 interface is defined between the Serving GW and HRPD PDSN and supports the forwarding of DL data 
during mobility from E-UTRAN to HRPD. Signalling procedures on the SlOl interface are used to set up tunnels on the 
SI 03 interface. 

The requirements for these interfaces are defined in 3GPP TS 23.402 [2]. 

The protocol stack used for the SlOl interface shall be based on GTPv2-C, see 3GPP TS 29.274 [6] Figure 4.3. 

The UDP header and port numbers definitions shall be as defined in GTPv2-C, see 3GPP TS 29.274 [6] section 4.3.1. 

The IP header and IP addresses definitions shall be as defined in GTPv2-C, see 3GPP TS 29.274 [6] section 4.3.2. 

Layer 1 and Layer 2 requirements shall as defined in GTPv2-C, see 3GPP TS 29.274 [6] sections 4.3.3 and 4.3.4. 
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5 Transmission Order and Bit Definitions 

Transmission Order and Bit Definitions shall be as defined in GTPv2-C, see 3GPP TS 29.274 [6] section 4.4. 



S101 IVIessage Header 



6.1 Introduction 

The SlOl Message Header is conformant to the GTPv2-C Message Header, see 3GPP TS 29.274 [6] section 5. All SlOl 
messages shall have a header that includes specific parameters. The following list of header parameters are defined for 
the SlOl interface: 

Version 

Flags (T = TEID Included, E = Extension Header Included) 

Message Type 

Length 



6.2 S101 IVIessage Header 



The SlOl header is a variable length header. The minimum length of the SlOl header is eight octets. Space has been 
reserved for three flags that may be used in the future to signal the presence of additional optional header fields. 

Bit 3 (the E bit) may be set to one to indicate that an Extension Header is present, as per 3GPP TS 29.274 [6]. 
The E bit shall be set to zero to indicate that the Extension Header field shall not be present in any message sent 
on the SlOl interface. 

Bit 4 (the T bit) may be set to one to indicate that a TEID is present in the header, as per 3GPP TS 29.274 [6]. 
The T bit shall be set to zero to indicate that the TEID field shall not be present in any message sent on the SlOl 
interface. 

If the header fields do not occupy a full eight octets, then spare octets shall be added after the last valid field in the SlOl 
header to complete eight octets. Spare octets and bits shall be set to zero. 

Always present fields: 

Version field: This field is used to determine the version of the SlOl protocol. The version number shall be set 
to '010'. 

Message Type: This field indicates the type of SlOl message. The valid values of the message type are defined 
in clause 7.1. Note that values chosen for Message Type shall be coordinated with and shall not overlap the 
Message Type values chosen for GTPv2-C in 3GPP TS 29.274 [6]. 

Length: This field indicates the length in octets of the payload, i.e. the rest of the packet following the 
mandatory part of the SlOl header (that is the first 4 octets). 

Sequence Number: This field enables the target system to identify any missing messages and is used for 
acknowledgement. 
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Octets 


Bits 
8 7 6 5 4 3 2 1 


1 


Version=010 (*) T=0 E=0 (*) (*) 


2 


Message Type 


3 


Length (1" Octet) 


4 


Length (2™ Octet) 


5 


Sequence Number (1^' Octet) 


6 


Sequence Number {2™ Octet) 


7 


Spare 


8 


Spare 



NOTE 0: (*) This bit is a spare bit. It shall be sent as '0'. The receiver shall not evaluate this bit. 

Figure 6.2-1 : Layout of the SI 01 Message Header 

S101 Messages and Message Formats 



7.1 



Introduction 



This section is divided into path management which defines the general messages for the pre-configured tunnel and a 
section for the specific messages used for information transfer over the control plane. 

Table 7.1 specifies GTPv2-C message types that are used across the SlOl interface. 

Table 7.1 : Message types for SI 01 



Message Type 
value (Decimal) 


Message 


Reference 





Reserved 


3GPP TS 29.274 [6] 


1 


Echo Request 


3GPP TS 29.274 [6] 


2 


Echo Response 


3GPP TS 29.274 [6] 


3 


Version Not Supported Indication 


3GPP TS 29.274 [6] 


4 


Direct Transfer Request message 


7.3.2 


5 


Direct Transfer Response message 


7.3.3 


6 


Notification Request message 


7.3.4 


7 


Notification Response message 


7.3.5 


8-24 


For future S1 01 interface use 




25-31 


Reserved for Sv interface 


3GPPTS 29.280 [14] 


32-255 


Reserved for GTPv2-C spec 


3GPP TS 29.274 [6] 



7.2 



7.2.1 



Path Management Messages 



IntrocJuction 



The path from the MME to the non-3GPP Access Network operationally requires management capabilities. The 
following GTPv2-C messages support path management for the SlOl interface: 

Echo Request 

Echo Response 

Version Not Supported 

These messages are defined for GTPv2-C and the handling and definition shall also be as defined in GTPv2-C, see 

3GPPTS 29.274 [6]. 
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7.2.2 Echo Request message 

An MME or an HRPD access node may send an Echo Request to find out if the peer HRPD access node or MME is 
alive (see section Path Failure). When and how often an Echo Request message may be sent is implementation specific 
but an Echo Request shall not be sent more often than every 60 s on each path. 

An MME or an HRPD access node shall be prepared to receive an Echo Request at any time and it shall reply with an 
Echo Response. The optional Private Extension contains vendor or operator specific information. 

3GPP TS 29.274 [6] specifies the information elements included in the Echo Request message. 



7.2.3 Echo Response message 

The message shall be sent as a response to a received Echo Request. 

3GPP TS 29.274 [6] specifies the information elements included in the Echo Response message. 

The Recovery information element contains the local Restart Counter (see section Restoration and Recovery) value for 
the node that sends the Echo Response message. 

The MME or an HRPD access node that receives an Echo Response from a peer MME or an HRPD access node shall 
compare the Restart Counter value received with the previous Restart Counter value stored for that peer MME or HRPD 
access node. If no previous value was stored, the Restart Counter value received in the Echo Response shall be stored 
for the peer MME or HRPD access node. 

The value of a Restart Counter previously stored for a peer MME or HRPD access node may differ from the Restart 
Counter value received in the Echo Response from that peer MME or HRPD access node. In this case, the MME or 
HRPD access node that sent the Echo Response shall be considered as restarted by the MME or HRPD access node that 
received the Echo Response. The new Restart Counter value received shall be stored by the receiving entity, replacing 
the value previously stored for the sending MME or HRPD access node. 

The optional Private Extension contains vendor or operator specific information. 



7.2.4 Version Not Supported message 



This message contains only the SlOl header and indicates the latest SlOl version that the MME or HRPD access node 
entity on the identified UDP/IP address can support (see subclause 6.2). 

3GPP TS 29.274 [6] specifies the detailed handling and information elements included in the Version Not Supported 

message. 



7.3 S101 Messages 



7.3.1 Introduction 

The following messages are used to support interworking between the MME and the non-3GPP access network: 
Direct Transfer Request 
Direct Transfer Response 
Notification Request 
Notification Response 

7.3.2 Direct Transfer Request message 

A Direct Transfer Request shall be sent from an MME or HRPD access node to transport an HRPD or an E-UTRAN 
message to the peer HRPD access node or MME. 
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Table 7.3.2-1 specifies the information elements included in the Direct Transfer message. 

Table 7.3.2-1 : Information Elements in a Direct Transfer Request 



Information elements 


Presence 
Requirement 


Reference 


Instance 


Session ID 


IVIandatory 


7.5.2 





HRPD Sector ID 


Conditional 


7.5.5 





S101 Transparent Container 


Mandatory 


7.5.6 





PDN GW PMIP GRE Tunnel Info 


Conditional 


7.5.9 





S103GRE Tunnel Info 


Conditional 


7.5.10 





S103HSGW IP Address 


Conditional 


7.5.11 





Handover Indicator 


Conditional 


7.5.7 





Tracking Area Identity 


Conditional 


7.5.12 





Recovery 


Conditional 


7.5.4 





Private Extension 


Optional 


7.5.8 


vs 



The HRPD Sector ID parameter shall be included if this message is being sent from the MME to the HRPD access node 
in case of handover from E-UTRAN to HRPD. 

If an HRPD message is being tunnelled between an MME and an HRPD access node, the SlOl Transparent Container 
shall contain the HRPD message. 

The Tracking Area Identity parameter shall be included if this message is being sent from the HRPD access node to the 
MME in case of handover from HRPD to E-UTRAN. 

If an E-UTRAN message is being tunnelled between an MME and an HRPD access node, the SlOl Transparent 
Container shall contain the E-UTRAN message. 

If the Direct Transfer Request message is sent from the MME to the HRPD AN and the MME has the PDN GW IP 
Address and the PDN GW GRE Key for a PDN Connection, the PDN GW PMIP GRE Tunnel Info IE shall be included 
when the MME receives CDMA2000 HO Required Indication from the eNodeB, see 3GPP TS 36.413 [12]. The PDN 
GW PMIP GRE Tunnel Info shall include the PDN Identity and the PDN GW GRE Key for the PDN connection. The 
S103 HSGW IP Address IE shall also be included in this case in the message but only one occurrence. The Handover 
Indicator shall indicate Handover Required in this case. For each PDN GW PMIP GRE Tunnel of the UE, there shall be 
a PDN GW PMIP GRE Tunnel Info Information Element included in the message. 

If the Handover Indicator IE indicates HO Ready during optimized active handover from E-UTRAN to HRPD, the 
SlOl Transparent Container contains the HRPD message (=HRPD TCA message). If data forwarding applies, S103 
GRE Tunnel Info field shall be included, which includes the PDN ID, HSGW Address and the HSGW GRE Key for a 
PDN connection. For each PDN connection of the UE which requires data forwarding towards the HSGW, there will be 
a S103 GRE Tunnel Info information element included in the message. 

The Handover Indicator parameter shall be included, if the encapsulated message being carried will cause the UE to 
leave the source system and tune its radio to the target system. It shall also be included for the case of LTE to HRPD 
handover, if a Direct Transfer Request message is sent from the MME to the HRPD AN, the MME shall include a 
Handover Required indication in the Handover Indicator IE, if a Handover Required was received by the MME from 
the eNodeB. 

If the node is contacting its peer for the first time or if the node has restarted recently and the new Restart Counter value 
has not yet been indicated to the peer, the Recovery IE shall be included. 

7.3.3 Direct Transfer Response message 

The message shall be sent from an MME or HRPD access node to its peer HRPD access node or MME as a response to 
a Direct Transfer Request. 

Table 7.3.3-1 specifies the information elements included in the Direct Transfer Response message. 
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Table 7.3.3-1 : Information Elements in a Direct Transfer Response message 



Information elements 


Presence 
Requirement 


Reference 


Instance 


Session ID 


IVlandatory 


7.5.2 





Cause 


IVIandatory 


7.5.3 





Recovery 


Optional 


7.5.4 





Private Extension 


Optional 


7.5.8 


vs 



The Cause value indicates that the encapsulated message was received. Possible Cause values are: 

"Request Accepted". 
- "System failure". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Optional IE incorrect". 

"Invalid message format". 
'No resources available' indicates that not enough resources are available within the receiving system. 

7.3.4 Notification Request message 

A Notification Request message shall be sent from an MME or HRPD access node to its peer HRPD access node or 
MME to notify its peer of a fact or event. 

Table 7.3.4-1 specifies the information elements included in the Notification Request message. 
Table 7.3.4-1 : Information Elements in a Notification Request 



Information elements 


Presence 
Requirement 


Reference 


Instance 


Session ID 


IVIandatory 


7.5.2 





Handover Indicator 


Conditional 


7.5.7 





Recovery 


Conditional 


7.5.4 





Private Extension 


Optional 


7.5.8 


vs 



The Handover Indicator information element (=HO Complete) shall be included if the sending system needs to notify 
the receiving system of the completion of a handover. 

The Handover Indicator information element (=Redirection) shall be included if the sending system needs to notify the 
receiving system of the SlOl tunnel end point redirection. 

The optional Private Extension contains vendor or operator specific information. 

If the Handover Indicator IE (= Redirection) and the node is contacting its peer for the first time or if the node has 
restarted recently and the new Restart Counter value has not yet been indicated to the peer , the Recovery IE shall be 
included. 

7.3.5 Notification Response message 

A Notification Response message shall be sent from an MME or HRPD access node to its peer HRPD access node or 
MME to acknowledge receipt of a Notification Request message. 

Table 7.3.5-1 specifies the information elements included in the Notification Response message. 
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Table 7.3.5-1 : Information Elements in a Notification Response message 



Information elements 


Presence 
Requirement 


Reference 


Instance 


Session ID 


IVlandatory 


7.5.2 





Cause 


IVIandatory 


7.5.3 





Recovery 


Optional 


7.5.4 





Private Extension 


Optional 


7.5.8 


vs 



If the MME or HRPD access node receives a Notification Response with a Cause value other than 'Notification 
Accepted', it should note and log the event and response. 

Possible Cause values are: 

"Notification Accepted". 

"System failure". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Optional IE incorrect". 

"Invalid message format". 

7.4 Reliable Delivery of Signalling IVIessages 

For the SlOl interface protocol, the reliable delivery of signalling messages shall have the same handling as GTPv2-C. 
See 3GPP TS 29.274 [6] but with SlOl node replacing GTPv2-C node as appropriate. 

For certain types of messages, i.e. Direct Transfer messages, retransmission at this layer level would be harmful to the 
session so for Direct Transfer messages retransmissions shall not be allowed and their N3-REQUESTS value shall be 
set to one, i.e. message is only sent once. 



7.5 



Information Elements 



7.5.1 Information Element Assignments 



An SlOl message may contain several information elements. The TLIV (Type, Length, Instance, Value) encoding 
format shall be used for all SlOl information elements. See TS 29.274 [6] subclause 8.2 for the general encoding of the 
lEs. 

Within information elements, certain fields may be described as spare. These bits shall be transmitted with the value 
defined for them. To allow for future features, the receiver shall not evaluate these bits. 

Table 7.5-1 : Information Elements 



IE Type 
Value 


Information Element 


Reference 


1 


Session ID 


7.5.2 


2 


Cause 


7.5.3 


3 


Recovery 


7.5.4 


4 


HRPD Sector ID 


7.5.5 


5 


SI 01 Transparent Container 


7.5.6 


6 


Handover Indicator 


7.5.7 


7 


PDN GW PMIP GRE Tunnel Info 


7.5.9 


8 


S103GRE Tunnel Info 


7.5.10 


9 


S103HSGW IP Address 


7.5.11 


10 


Tracking Area Identity 


7.5.12 


11-50 


For future use. Shall not be sent. If received, 
shall be treated as an Unknown IE. 
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IE Type 
Value 


Information Element 


Reference 


1 


Session ID 


7.5.2 


51-70 


Reserved for Sv interface. Sliall not be sent. 
If received, shall be treated as an Unknown 
IE. 


3GPPTS 
29.280 [14] 


70-254 


Reserved for GTPv2-C. Shall not be sent. If 
received, shall be treated as an Unknown IE. 


3GPPTS 
29.274 [6] 


255 


Private Extension 


7.5.8 
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7.5.2 Session ID 

The IMSI is used for the parameter Session ID; see 3GPP TS 23.402 [2]; so for SlOl this Information Element is 
mandatory for all SlOl messages apart from the path management messages and shall always be the first IE following 
the SlOl Header. The Session ID IE shall be encoded as the International Mobile Station Identity information element 
as defined in 3GPP TS 29.274 [6]. 

7.5.3 Cause 

In a response, the Cause Value shall indicate the acceptance or the rejection of the corresponding request. The Cause 
value shall be included in the response message. 

"Request accepted" shall be returned when an MME or an HRPD Access has accepted a request. 

"Notification accepted" shall be returned when an MME or an HRPD Access has accepted a notification. 

"No memory available" shall indicate that the MME or an HRPD Access does not have enough memory to use. 

"System failure" shall indicate that a generic permanent error condition has occurred. 

"Invalid message format", "Mandatory IE incorrect", "Mandatory IE missing" and "Optional IE incorrect" shall indicate 
protocol errors as described in the section on Error handling. 

Refer to 3GPP TS 29.274 [6] for the encoding of this Information Element. 

Table 7.5.3-1 Cause Values used on the 8101 Interface 



Message Type 


Cause value 
(decimal) 


Meaning 







Reserved. Shall not be sent and if received the Cause shall be treated as an 
invalid IE 


Request 






1-15 


Spare. This value range is reserved for Cause values in a request message 


Acceptance 
Response 


16 


Request accepted 


17 


Request accepted partially 


18-63 


Spare. This value range is reserved for Cause values in acceptance response 
message 


Rejection 
Response 


64 


Context Non Existent/Found 


65 


Invalid Message Format 


66 


Spare 


67 


Invalid length 


68 


Service not supported 


69 


IVIandatory IE incorrect 


70 


Mandatory IE missing 


71 


Optional IE incorrect 


72 


System failure 


73 


No resources available 


74-255 


Spare. This value range is reserved for Cause values in rejection response 
message 



NOTE: In the first release of the present document the value of the length field of this IE is 1 for cause values 

without "offending IE", and 4 + the length of the offending IE for those including it. In future releases of 
the specification additional octets may be specified. The legacy receiving entity simply ignores the 
unknown octets and values in the spare bits. 

7.5.4 Recovery 

The Recovery information element shall indicate if the peer MME or HRPD Access has restarted. Refer to 3GPP TS 
29.274 [6] for the encoding of this Information Element. 
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7.5.5 HRPD Sector ID 

The HRPD Sector ID information element shall provide a reference in the target system that can be used to create a 
unique mapping to an HRPD Access or MME that is appropriate to operate as the peer entity for an SlOl interface 
tunnel. 

The HRPD Sector Identifier is defined in 3GPP2 C.S0024-A [7] section 14.9.2.2. 

The E-UTRAN Access makes the HRPD Sector ID available by provisioning this in the E-UTRAN Access equipment. 

Table 7.5.5-1 : HRPD Sector ID IE 



Octets 

1 
2 to 3 

4 
5 to 20 


Bits 
8 7 6 5 4 3 2 


1 




Type = 4 




Length = 16 


Spare Instance 


HRPD Sector Identifier 



7.5.6 S1 01 Transparent Container 

The SlOl Transparent Container information element shall contain an encapsulated HRPD message or an encapsulated 
E-UTRAN message that is either generated by the UE and is being transferred to the MME or HRPD access, or is 
generated by the MME or HRPD access and is being transferred to the UE. It is variable in length and shall always be 
an integral number of octets. The highest numbered octet shall be filled, if necessary, with extra bits set to '0' in the low 
order bit positions to create an integral number of octets. 

Table 7.5.6-1 : SI 01 Transparent Container IE 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 5 




Length = n 


Spare Instance 


S101 Transparent Container 



The format of an encapsulated E-UTRAN message is defined in 3GPP TS 24.301 [10]. 
The format of the encapsulated HRPD messages is defined in 3GPP2 C.S0087-0 [9]. 

7.5.7 Handover Indicator 

The Handover Indicator information element shall indicate the status of the Handover to the receiving system as a result 
of the encapsulated message carried in an SlOl Transparent Container message. 

Table 7.5.7-1 : Handover Indicator IE 



Octets 

1 

2 to 3 

4 

5 


Bits 
8 7 6 5 4 3 2 


1 




Type = 6 




Length = 1 


Spare Instance 


Handover Indicator 
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Table 7.5.7-2: Handover Indicator 



Handover 


Meaning 


Indicator 




(Decimal) 







Not Used 


1 


HO Ready 


2 


HO Failure 


3 


HO Complete 


4 


Redirection 


5 


HO Required 


All Others 


Spare 



7.5.8 Private Extension 

The Private Extension information element shall contain vendor specific information. Refer to 3GPP TS 29.274 [6] for 
the encoding of this Information Element. 

7.5.9 PDN GW PMIP GRE Tunnel Info 

The PDN GW PMIP GRE Tunnel Info shall contain: the PDN Identity, i.e. APN, the PDN GW Address and the PDN 
GW GRE Key, which identifies a PMIP GRE tunnel towards a PDN GW. 

Table 7.5.9-1 : PDN GW PMIP GRE Tunnel Info IE 



Octets 

1 

2 to 3 

4 

5 

6 to (m+5) 

m+6 

(m+7) to 

(k+m+6) 

(k+m+7) to 

(k+m+10) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 7 




Length = n 


Spare Instance 


PDN Identity Length = m 


PDN Identity (=APN) 


PDN GW IP Address Length = k 


PDNGW IP Address 


PDN GW GRE Key 



7.5.10 S1 03 GRE Tunnel Info 

The SI 03 GRE Tunnel Info IE shall contain the PDN Identity and HSGW GRE Key, which identifies a GRE tunnel 
towards a HSGW. 

Table 7.5.10-1 : S103 GRE Tunnel Info IE 



Octets 

1 

2 to 3 

4 

5 

6 to (m+5) 

(m+6) to 

(m+9) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 8 




Length = n 


Spare Instance 


PDN Identity Length = m 


PDN Identity (=APN) 


HSGW GRE Key 



7.5.1 1 SI 03 HSGW IP Address 

The S103 HSGW IP Address IE shall contain S103 HSGW IP Address. 
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Table 7.5.11-1: S1 03 HSGW IP Address 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 9 




Length = n 


Spare Instance 


S103 HSGW IP Address 



7.5.12 Tracking Area Identity 

The Tracking Area Identity information element shall provide a reference in the MME that can be used to assign a 
Tracking Area or list of Tracking Areas to which the UE is registered. 

The HRPD Access makes the E-UTRAN TAJ available by provisioning this in the HRPD equipment. 



Table 7.5.12-1 : Tracking Area Identity IE 



Octets 

1 
2 to 3 

4 
5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 1 




Length = n 


Spare Instance 


Tracking Area Identity 
as specified in 3GPP TS 24.301 [10] 



8 



Path Protocols 



Path handling is specified in 3GPP TS 29.274 [6]. 



Error Handling 



9.1 



Protocol Errors 



See 3GPP TS 29.274 [6] section 7.5 for the complete specification of protocol error handling. 

9.2 Path Failure 

See 3GPP TS 29.274 [6] for the complete specification of the path failure procedures. 

9.3 Restoration and Recovery 

See 3GPP TS 23.007 [8] for the complete specification of the restoration and recovery procedures. 



1 Security provided to Communication over the S1 01 
Interface 

Protection of communication over the SlOl interfaces shall be provided according to security mechanisms defined in 
3GPPTS 33.402 [11]. 
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11 IP - The Networking Technology used by SI 01 

11.1 IP Version 

See 3GPP TS 29.274 [6] for the complete specification of the IP versions supported over the GTPv2-C like SlOl. 

11.2 IP Fragmentation 

See 3GPP TS 29.274 [6] for the complete specification of the fragmentation procedures used in SlOl. 



12 SI 01 Parameters 

12.1 General 

The SlOl interface system parameters defined and their recommended values shall not be fixed but it shall be possible 
to configure them as described in 3GPP TS 29.274 [6]. 

12.2 Timers 

See 3GPP TS 29.274 [6] for the complete specification of the timers and their recommended values used over SlOl, e.^ 
response time to wait for a request message. 

12.3 Others 

See 3GPP TS 29.274 [6] for the complete specification of the maximum number of retry attempts to resend a request 
message used over SlOl. 



13 SI 03 Interface Specification 

13.1 Introduction 

The SI 03 interface is defined between the Serving GW and HRPD PDSN and supports the forwarding of DL data 
during mobility between E-UTRAN and HRPD access networks. Signalling procedures on the SlOl interface, 
documented in 3GPP TS 23.402 [2], are used to set up tunnels on the S103 user plane interface. 

13.2 3103 Interface 

The S103 interface protocol stack and signalling requirements are specified in 3GPP TS 23.402 [2]. The S103 interface 
shall use Generic Routing Encapsulation as specified in IETF RFC 2784 [4] including the Key and Sequence Number 
Extensions to GRE in IETF RFC 2890 [5]. The Key Field value of each GRE packet header shall uniquely identify the 
UE-PDN connection. 
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